In many computer operating systems, printing tasks are divided between several well-known processes or functions. FIG. 1 shows the relationship between these processes for an exemplary POSTSCRIPT driver 22 in a MICROSOFT Windows-type operating system (OS) environment. A printer driver 22 accepts operating-system-specific printing instructions, from applications (or, more generally, other processes) 20, and converts these instructions to a rendered format or to a metafile (i.e., the driver journals the printing instructions for delayed background rendering). Rendered/journaled print data is combined with other information (e.g., printer job language commands) to form a print job. The print job is spooled to a spooler 24, which implements a queue for the print data from driver 22, and therefore allows the driver to generate multiple print jobs while a first job is pending on the printer. Either immediately or delayed, the spooler despools the print job to a print processor 26. Print processor 26 performs different functions depending on the operating system. Generally, if the print data is journaled (e.g., Extended MetaFile or EMF) data, print processor 26 passes the journaled data back through the printer driver 22. Otherwise, in the case of rendered print data, print processor 26 despools the print data to a port manager 28 that actually performs data communication with the printer.
Printer drivers are generally printer specific and operating-system specific, as these drivers must convert the operating system printing instructions to a Page Description Language (PDL) or raster format understandable by the particular printer they are supporting, and may encapsulate that data in a specific Printer Job Language (PJL) to implement other printer functions (e.g., stapling, sorting). Hewlett Packard PCL (Printer Control Language) and Adobe PS (POSTSCRIPT) are two prevalent formats for printer communications, although different printers may provide different levels of support for these formats, and/or additional features not directly supported by these standard formats.
In FIG. 1, POSTSCRIPT driver 22 is described as a monolithic PS driver, meaning that this driver is written to implement PS functionality specifically for the printer (or group of printers with common features) that this driver supports. A monolithic driver would include, e.g., a printer-specific menu to allow a user to control the available print options, a MICROSOFT OS Device Driver Interface (OSDDI) to process printing instructions received from applications, a renderer to generate PS print data specific to the printer, and a PJL generator to actuate the printer's special features.
A monolithic driver requires a one-time cost to design and develop the driver from scratch—a cost that may be significant. Rivaling this cost is the additional cost to test and debug the driver, and then package it. The driver must then be maintained. Although historically many printer drivers were implemented this way, monolithic drivers are generally no longer cost effective given the regular introduction of new operating systems and printer models with different feature sets, and the complexity of both. Each supported operating system requires its own test and debug procedure, each time an incremental modification is made to the existing driver. Thus the ongoing costs to a printer manufacturer from such an approach are significant.
FIG. 2 shows an alternate approach that saves some development costs. Source code for a generic PS driver 34 is purchased from a vendor (e.g., Adobe POSTSCRIPT 3.0). The printer manufacturer then adds customizations 36 to the driver source code that are appropriate for the specific printer to be supported, to create a driver 32. The generic driver vendor generally charges a royalty for each copy of the driver distributed. Thus although this approach saves some money upfront, it requires that one learn the source code for the existing driver, integrate patches and updates from the vendor into the driver, and maintain the customizations. Further, this approach does not decrease test, debug, and packaging costs or alleviate costs associated with revisions and updates, and adds an additional fixed cost to every printer sold.
Both APPLE and MICROSOFT supply configurable PS printer drivers free of charge, as part of their operating systems, which read PPD (POSTSCRIPT Printer Definition) files (use of PPD files is not limited to these operating system families, however). Taking the MICROSOFT driver as an example (see FIG. 3), a printer manufacturer can use the MICROSOFT OS base PS driver 42 by describing and storing the specifics of the manufacturer's printer in PPD file 40. The base PS driver 42 reads the PPD file when it is called upon to render a print job for the corresponding printer.
The PPD is a text file, with each non-comment line having a *feature:value format such as: *DefaultFont: Courier (setting the printer's default font); *ImageableArea A3/A3: “14 14 828 1178” (setting the printable area for A3 paper); *DefaultResolution: 600 dpi (printer resolution). Various toolkits are available to generate a PPD file from a menu-driven interface.
The PPD approach has some appeal—it does not require that a printer driver be written from scratch or maintained, it allows for customization, it is generally portable, and does not require royalties. Also, although each time the PPD is changed it must be tested, in general it need not be tested for each operating system.
The PPD approach also has a few drawbacks. Although a rich set of PPD predefined features and options are available, this set is nevertheless limited and would not include new features that a manufacturer might develop. The manufacturer cannot add such features to the PPD, and cannot modify the corresponding “free” driver since no source code is supplied. Thus with a PPD PS driver there is no way to configure the driver to take advantage of newly discovered features that might set a manufacturer apart from the competition.